1. Field of the Invention
The present invention relates to detecting hidden files and folders that may be installed by or as part of a rootkit.
2. Description of the Related Art
A file system filter driver is an optional driver that adds value to or modifies the behavior of another driver—specifically, a file system. It is a kernel-mode component that runs as part of an operating system, such as the Microsoft® Windows NT® executive.
A file system filter driver can filter I/O operations for one or more file systems or file system volumes. Depending on the nature of the driver, the filter can log, observe, or modify file system events, or the filter can even prevent file system events from occurring. Typical applications for file system filter drivers include antivirus utilities, encryption programs, and hierarchical storage management systems.
A file system filter driver works in conjunction with one or more file systems to manage file I/O operations. These operations include creating, opening, closing, and enumerating files and directories; getting and setting file, directory, and volume information; and reading and writing and file data. In addition, file system filter drivers must support file system-specific features such as caching, locking, sparse files, disk quotas, compression, security, recoverability, reparse points, and volume mount points.
A file system filter driver attaches itself to one or more mounted volumes and filters all I/O operations on the volume.
A rootkit is a set of software tools intended to conceal running processes, files or system data, thereby helping an intruder to maintain access to a system whilst avoiding detection. Rootkits are known to exist for a variety of operating systems such as Linux, Solaris and versions of Microsoft Windows. Rootkits often modify parts of the operating system or install themselves as drivers or kernel modules. The file system is of special interest to rootkits for stealth reasons. Many rootkits need to store files in the file system, and these must remain hidden. Therefore some rootkits install a file system filter driver to hide their files and their folders from other entities in the system.
For example, Greg Hoglund and James Butler have presented a file system filter driver rootkit that filters the IRP_MJ_DIRECTORY_CONTROL and IRP_MN_QUERY_DIRECTORY requests sent to the file system volume devices. These filter drivers create filter device objects and attach them to the base file system volume device objects. In its I/O completion routine, the rootkit filter driver modifies the returned buffer to remove any reference to any folder or file that the rootkit hides.
The current known approaches to detect hidden files and folders are based on parsing the on disk file structure to detect hidden files and folders. For example, the MICROSOFT® WINDOWS® NTFS® on disk metadata may be parsed to enumerate folders and files within those folders and then a similar query may be sent to the Windows I/O manager. The difference is taken between both results to detect hidden files and hidden folders.
Although such methods are very efficient and can reveal any hidden files and hidden folders that are made hidden from the Windows NT I/O manager, they suffer from a number of limitations or drawbacks. For example, such techniques do not identify the method that is used to hide files and folders. These methods vary from hooking the NT SSDT, or through using a file system filter driver. Therefore, they would detect hidden objects but will not provide enough information to remove the rootkit code from memory. Further, the NTFS on disk structure is not officially documented by Microsoft. All the available information is based on reverse engineering. Therefore the file system structure parsing code can get broken anytime Microsoft changes the NTFS on disk structure. So portability is a major issue facing those techniques. Finally, reading the NTFS on disk structure is suitable for offline forensic analyses purposes more than for real-time detection of hidden files and folders. This is because during the time the NTFS on disk structure is read by the rootkit detection code the NTFS driver may have kept some changes in its runtime memory cache to be flushed later on to the disk. Therefore, there is always a chance for an error between the actually reality and what the rootkit detection code can see.
Thus, a need arises for a technique by which hidden files and folders that may be installed by or as part of a rootkit may be detected that identifies the method that is used to hide the files and folders, that will continue working even if the operating system is modified, and that is suitable for real-time detection of hidden files and folders.